The invention relates to chip cards, also referred to as microcontroller cards or integrated circuit cards, and more generally open programmable data processing means able to be loaded with applications written in high-level programming languages.
An open chip card, as presented for example in the document WO 98/19237, manages several applications, for example a customer account for a shop, a bank account or an electronic purse. Some applications loaded in the card sometimes cooperate for example in order to pay for a purchase from the shop, and/or also cooperate with applications executed outside the card.
Cooperation of the applications makes it possible to establish access right rules, the applications not necessarily trusting each other. For example, the customer account managed by the shop must not appropriate data managed by the electronic purse.
In a data processing environment, management of the access control consists in associating rights of access with objects managed in the environment for each user, and checking that these access rights are complied with.
Management of the access control is shown schematically in FIG. 1 by the management of an access matrix MA. The rows in the matrix MA correspond to the rights of J objects O1 to OJ and the columns in this matrix correspond to the rights of I users U1 to UI. A box in the matrix at the intersection of a row and column gives access rights Dij of a user Ui to an object Oj, with 1=i=I and 1=j=J, for example a right to read from, write to or execute a file.
In practice, the matrix MA is partially empty, users often having no right over many objects, and has one of the two configurations consisting of a grouping of the access rights by row and a grouping of access rights by column.
Grouping by row amounts to associating with each object Oj an access list indicating the access rights D1j to DIj over the object respectively for the users U1 to UI. In a management by lists of accesses respectively associated with objects, only the owner of an object Oj modifies the access list D1j to DIj associated with the object; such a modification takes place explicitly by invoking an operation on the object requiring the modification of its access list. The protection schemes based on access lists are then termed static, the modification of the access rights being complex and the users having a tendency to oversize the access rights of their objects. This runs counter to the principle of least privilege (known in English as the need to know principle) according to which access rights are granted only as needs occur.
Grouping by column associates with each user UI a list of capabilities indicating the access rights Di1 to DiJ of the user respectively for the objects over which the user has a right. Each element (Oj, Dij) in the list is called a capability. A capability is a descriptor containing the identification of an object Oj and a definition of access rights Dij over this object. In management by capabilities, a user has a list of capabilities, a capability being able to be compared with a token giving the right to carry out an operation on the object. A capability identifies an object, but also includes a definition of the rights of access over the object. A capability can then be utilised as an object identifier which an application can pass as a parameter to another application, following a conventional programming mode, with the limitation that this identifier does not enable all operations on the designated object.
The result is that the modification of the access rights is more natural with capabilities: granting to an application or a user access rights to an object amounts to passing to it as a parameter of an operation the identity of the object in the form of a capability.
Capabilities afford greater dynamics in the management of the access control, the access rights being able to be easily exchanged between the users of the environment. However, when a user or an application must pass as a parameter a capability on an object, the user or the application must decide in advance on the rights to be transferred with the capability. An operation makes it possible in general to reduce the rights associated with the capability if necessary, before passing it as a parameter.
In the prior art, hardware implementations and software implementations of the capabilities comparable to tokens are known. The first hardware implementations were based on specialist machines in the 1970s. The addressing mechanism of these machines directly established the concept of capability: an address register serving to address an object also contains the rights of access to the object (the register containing the token). The values of these registers could be exchanged between users, but could not be forged, the hardware not permitting this. The software implementations, more recent in the 1980s, were based on enciphering for the protection of the capabilities. A capability was signed and could be created only by the owner of the object.
Thus the document U.S. Pat. No. 5,781,633 illustrates a prior technique allowing filtering, by means of capabilities, of exchanges of object references between different processes. Cryptographic methods are used to guarantee mainly the integrity of the references exchanged. Cooperation between processes is achieved by the transmission of a reduced view of an object of a process, to a second process. The filter thus created is located within the process requesting access. In a context of the “mutually mistrusting process” type, the method disclosed by the document is inoperative. This is because the process requesting access may as it pleases modify the filter which was transmitted to it and thus access methods which are however prohibited to it.